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INTRODUCTION 

The  need  to  wait  on  more  than  64  handles  was  first  encountered  while  upgrading  some  old 
software  to  run  more  efficiently  by  breaking  down  tasks  to  run  in  multiple  worker  threads.  Almost 
200  threads  were  spawned  and  then  it  was  found  that  there  was  a  maximum  number  of  handles  that 
could  be  waited  on.  The  maximum  was  set  by  a  global  definition  of  MAXIMUM_WAIT_OBJECTS, 
which  equals  64.  All  of  the  threads/tasks  needed  to  be  completed  first  in  order  to  report  the 
completion  of  the  process  to  the  calling  function. 


METHODOLOGY 

The  initial  situation  presented  was  having  all  of  the  handles  to  the  threads  inside  a 
std::vector.  The  general  idea  to  handle  this  situation  was  to  break  down  the  number  of  thread 
handles  into  64  or  less  chunks  and  spawn  a  subsequent  thread  for  each  group.  That  thread  would 
then  wait  on  the  64  thread  handles  of  that  group.  Then,  one  would  wait  on  all  the  handles  produced 
by  spawning  a  thread  for  each  group. 

The  following  sequence  is  the  block  of  code/algorithm  that  was  created  for  the  situation  of 
having  more  than  64  handles: 


std::vector<HANDLE>  new_handles; 

int  threads_needed  =  FCT_Threads.size()  /  MAXIMUM_WAIT_OBJECTS; 
threads_needed  +=  ((FCT_Threads.size()  %  MAXIMUM_WAIT_OBJECTS)  ==  0)  ?  0  :  1; 
for(int  i  =  0;  i  <  threads_needed;  ++i) 

{ 

WaitThreadData*  data  =  new  WaitThreadData; 
if((i  +  1)  <  threads_needed) 

{ 

data->quantity  =  MAXIMUM_WAIT_OBJECTS; 

memcpy_s(data->handles,  sizeof(HANDLE)  *  MAXIMUM_WAIT_OBJECTS,  &FCT_Threads[i  *  MAXIMUM_WAIT_OBJECTS], 
sizeof(HANDLE)  *  MAXIMUM_WAIT_OBJECTS); 

} 

else 

{ 

//partial  group 

data->quantity  =  FCT_Threads.size()  %  MAXIMUM_WAIT_OBJECTS; 

memcpy_s(data->handles,  sizeof(HANDLE)  *  data->quantity,  &FCT_Threads[i  *  MAXIMUM_WAIT_OBJECTS]/  sizeof(HANDLE)  *  data- 
>quantity); 

} 

HANDLE  ct  =  CreateThread(NULL,  0,  CFCT_GenDlg::WaitThreads,  (LPVOID)data,  0,  NULL); 
new_handles.push_back(ct); 

} 

unsigned  long  ret  =  WaitForMultipleObjects(new_handles.size(),  new_handles.data(),  true,  INFINITE); 

The  first  step  the  code  takes  is  to  figure  out  how  many  threads  need  to  spawn.  This  is 
achieved  by  dividing  by  the  maximum  wait  objects  and  then  checking  for  a  remainder.  If  there  is  a 
remainder,  then  an  additional  thread  will  be  needed  for  the  partial  group.  The  next  step  is  to  iterate 
once  for  the  number  of  threads  needed,  filling  the  parameter  struct  appropriately.  The  parameter 
stuct  is  comprised  of  an  array  of  handles  with  a  maximum  size  of  MAX_WAIT_OBJECTS  and  an 
integer  holding  the  total  quantity. 

Once  all  the  “waitthreads”  are  created,  a  final  wait  is  initiated  on  the  current  thread  with  the 
handles  of  all  the  created  “waitthreads.”  Upon  return,  all  the  threads  would  have  completed  running 
their  tasks  and  can  be  cleaned  up. 
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CONCLUSIONS 

This  code  snippet  is  not  the  silver  bullet  for  all  problems  associated  with  waiting  on  more  than 
64  handles.  It  will,  however,  work  for  up  to  4,096  generated  threads.  It  does  give  a  very  good 
starting  point  for  anyone  dealing  with  a  similar  issue. 
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